L’adresse 0.0.0.0 au cœur d’une très vieille faille de sécurité dans les navigateurs

La société de sécurité Oligo a publié hier un billet dans lequel elle explique avoir alerté les fournisseurs de navigateurs au sujet d’une faille critique. Elle réside dans la manière dont ils gèrent l’adresse 0.0.0.0, pouvant renvoyer des pirates vers des ressources locales et une exécution de code à distance.

0.0.0.0 Day : c’est le nom donné par la société israélienne Oligo à cette faille présente dans Chrome, Firefox et Safari. Elle n’a rien de nouveau pourtant, puisqu’elle remonte dans certains cas à 18 ans. Oligo précise toutefois qu’elle a été découverte « récemment ».

L’adresse IP 0.0.0.0 est particulière et n’a pas la même signification selon le contexte. Sur Wikipédia, on trouve les deux cas les plus courants. Dans le contexte d’un serveur par exemple, elle a valeur de « toutes les adresses IPv4 de la machine locale ». Dans le domaine du routage en revanche, elle signifie le plus souvent « route par défaut ». En IPv6, plutôt que d’écrire une longue chaine de zéros, on utilise la notation « :: ».

Quel lien avec les navigateurs ? « Ce problème découle de la mise en œuvre incohérente des mécanismes de sécurité dans les différents navigateurs, ainsi que d'un manque de normalisation dans l'industrie des navigateurs », résume Oligo.

Tous les navigateurs, sauf sur Windows

La vulnérabilité trouvée est décrite comme « fondamentale » et « logique ». Elle réside aussi bien dans Chromium que dans Firefox et Safari. macOS et Linux sont concernés, mais pas Windows. Microsoft a en effet décidé de bloquer l’adresse 0.0.0.0 il y a plusieurs années.

Le problème découvert par Oligo réside dans la manière dont les navigateurs traitent les requêtes vers la fameuse adresse IP. Elle peut être utilisée pour exploiter des services locaux. Un site web public (comme les domaines finissant en .com, .fr, etc.) sont « capables de communiquer avec des services fonctionnant sur le réseau local (localhost) et potentiellement d'exécuter un code arbitraire sur l'hôte du visiteur en utilisant l'adresse 0.0.0.0 au lieu de localhost/127.0.0.1 », explique Oligo.

En clair, toute application s'exécutant sur localhost et accessible via 0.0.0.0 est susceptible d'exécuter du code à distance. Les pirates peuvent alors former une requête malveillante et l’expédier vers l’adresse 0.0.0.0 de la victime, dans l’espoir d’accéder à des ressources locales. S’ils y parviennent, de nombreuses possibilités s’ouvrent à eux, avec un vaste choix de vecteurs pour d’autres attaques.

Un grand nombre de configurations vulnérables

En pratique, Oligo estime que la faille concerne surtout les particuliers et les entreprises hébergeant des serveurs web pour certains scénarios, dont les tests en développement. Mais même ainsi, les chercheurs pensent que le nombre de configurations vulnérables est très élevé.

En mars dernier, une cyberattaque avait par exemple détourné de la puissance de calcul à des fins de minage de cryptoactifs en détournant le logiciel Ray, rapportait Forbes. Ray est utilisé par de nombreuses grandes entreprises pour l’entrainement des modèles d’IA. Une configuration à base de localhost et une API non protégée rendaient l’attaque possible. Anyscale, qui supervise le développement de Ray, avait protesté. L’entreprise renvoyait vers son guide de configuration, qui déconseillait fortement d’exposer Ray à du trafic réseau non fiable.

« Lorsque les services utilisent localhost, ils supposent un environnement contraint. Cette hypothèse, qui peut (comme dans le cas de cette vulnérabilité) être erronée, donne lieu à des implémentations de serveurs non sécurisées », résume Avi Lumelsky, principal chercheur derrière l’étude d’Oligo.

Les entreprises travaillent à colmater la brèche

Apple a confirmé auprès de Forbes travailler sur la question. Lors d’une prochaine bêta de macOS Sequoia, le problème ne devrait plus exister. Safari 18 devrait complètement bloquer l’adresse 0.0.0.0 dans le nouveau macOS. Les nouvelles versions du navigateur étant répercutées sur le système précédent, Sonoma en bénéficiera également. La situation est plus floue pour les moutures plus anciennes.

Chez Google, la prochaine révision 128 de Chrome commencera à bloquer elle aussi l’adresse 0.0.0.0. Ce changement sera déployé progressivement au cours des prochaines versions, jusqu’à un blocage total pour Chrome 133.

Dans la fiche explicative de Google, on peut lire que cette mesure est adoptée avant que Private Network Access n’entre en jeu. PNA est une spécification (toujours en brouillon) pour un mécanisme visant à limiter « la capacité des sites Web à envoyer des requêtes aux serveurs situés sur des réseaux privés ». PNA étend également le protocole CORS (Cross-Origin Resource Sharing). Avec PNA, les sites web doivent donc demander explicitement l’autorisation aux serveurs situés sur des réseaux privés pour leur envoyer des requêtes. Or, la faille découverte par Oligo permet de contourner entièrement PNA.

Chez Mozilla, c’est un peu plus compliqué. Firefox va adopter Private Network Access, mais ne compte pas bloquer immédiatement l’adresse 0.0.0.0. Le navigateur n’ayant jamais restreint l’accès au réseau privé, il n’y a pas de faille à proprement parler. Après l’avertissement d’Oligo, Mozilla a quand même proposé un changement de la spécification Fetch pour introduire le blocage 0.0.0.0. « Imposer des restrictions plus strictes comporte un risque important d'introduire des problèmes de compatibilité », a cependant déclaré Mozilla à Forbes.

Oligo présentera ses découvertes plus en détail le 10 août, lors de la DEF CON qui se tient à Las Vegas.